• Questions and Answers
  • Exam Tips
answers

CKA Simulator B Kubernetes 1.33

https://killer.sh

 

Each question needs to be solved on a specific instance other than your main candidate@terminal. You'll need to connect to the correct instance via ssh, the command is provided before each question. To connect to a different instance you always need to return first to your main terminal by running the exit command, from there you can connect to a different one.

In the real exam each question will be solved on a different instance whereas in the simulator multiple questions will be solved on same instances.

Use sudo -i to become root on any node in case necessary.

 

 

Question 1 | DNS / FQDN / Headless Service

 

Solve this question on: ssh cka6016

 

The Deployment controller in Namespace lima-control communicates with various cluster internal endpoints by using their DNS FQDN values.

Update the ConfigMap used by the Deployment with the correct FQDN values for:

  1. DNS_1: Service kubernetes in Namespace default

  2. DNS_2: Headless Service department in Namespace lima-workload

  3. DNS_3: Pod section100 in Namespace lima-workload. It should work even if the Pod IP changes

  4. DNS_4: A Pod with IP 1.2.3.4 in Namespace kube-system

Ensure the Deployment works with the updated values.

 

ℹ️ You can use nslookup inside a Pod of the controller Deployment

 

Answer:

For this question we need to understand how cluster internal DNS works in Kubernetes. The most common use is SERVICE.NAMESPACE.svc.cluster.local which will resolve to the IP address of the Kubernetes Service. Note that we're asked to specify the FQDNs here so short values like SERVICE.NAMESPACE are not possible even if they would work.

Let's exec into the Pod for testing:

We can perform DNS queries using nslookup and see if they resolve into an IP address.

 

Step 1

By default there is the kubernetes Service in default Namespace which can be used to access the K8s Api:

And we already have the value for DNS_1 which is kubernetes.default.svc.cluster.local, that was the easy one.

 

Step 2

The next one is similar:

The value for DNS_2 is department.lima-workload.svc.cluster.local. It is the same structure as before but what's interesting here is that we get two IP addresses. These are the IP addresses of the Pods behind that Service.

This is the case because the Service is headless and doesn't have its own IP address, but it still has Endpoints and points properly to Pods:

This means the decision which Pod IP to contact is now in the hands of the application which performed the DNS query of the headless Service.

 

Step 3

Now things start to get spicy, because we can do this:

Hence the value for DNS_3 is section100.section.lima-workload.svc.cluster.local.

But this is only possible because the Pods behind the Service specify hostname and subdomain like this:

 

Step 4

It's possible to resolve a FQDN like IP.NAMESPACE.pod.cluster.local into an IP address:

This is possible even without a Pod having to exist with that IP address in that Namespace.

We set DNS_4 to 1-2-3-4.kube-system.pod.cluster.local.

 

Solution

We should update the ConfigMap:

And restart the Deployment:

And the Pod logs also look happy now:

 

 

Question 2 | Create a Static Pod and Service

 

Solve this question on: ssh cka2560

 

Create a Static Pod named my-static-pod in Namespace default on the controlplane node. It should be of image nginx:1-alpine and have resource requests for 10m CPU and 20Mi memory.

Create a NodePort Service named static-pod-service which exposes that static Pod on port 80.

 

ℹ️ For verification check if the new Service has one Endpoint. It should also be possible to access the Pod via the cka2560 internal IP address, like using curl 192.168.100.31:NODE_PORT

 

 

Answer:

Then edit the my-static-pod.yaml to add the requested resource requests:

And make sure it's running:

Now we expose that static Pod:

This will generate a Service yaml like:

Then we check the Service and Endpoints:

Also we should be able to access that Nginx container, your NodePort might be different than the one used here:

 

 

Question 3 | Kubelet client/server cert info

 

Solve this question on: ssh cka5248

 

Node cka5248-node1 has been added to the cluster using kubeadm and TLS bootstrapping.

Find the Issuer and Extended Key Usage values on cka5248-node1 for:

  1. Kubelet Client Certificate, the one used for outgoing connections to the kube-apiserver

  2. Kubelet Server Certificate, the one used for incoming connections from the kube-apiserver

Write the information into file /opt/course/3/certificate-info.txt.

 

ℹ️ You can connect to the worker node using ssh cka5248-node1 from cka5248

 

 

Answer:

First we check the kubelet client certificate:

Next we check the kubelet server certificate:

We see that the server certificate was generated on the worker node itself and the client certificate was issued by the Kubernetes api. The Extended Key Usage also shows if it's for client or server authentication.

The solution file should look something like this:

 

 

Question 4 | Pod Ready if Service is reachable

 

Solve this question on: ssh cka3200

 

Do the following in Namespace default:

  • Create a Pod named ready-if-service-ready of image nginx:1-alpine

  • Configure a LivenessProbe which simply executes command true

  • Configure a ReadinessProbe which does check if the url http://service-am-i-ready:80 is reachable, you can use wget -T2 -O- http://service-am-i-ready:80 for this

  • Start the Pod and confirm it isn't ready because of the ReadinessProbe.

Then:

  • Create a second Pod named am-i-ready of image nginx:1-alpine with label id: cross-server-ready

  • The already existing Service service-am-i-ready should now have that second Pod as endpoint

  • Now the first Pod should be in ready state, check that

 

Answer:

It's a bit of an anti-pattern for one Pod to check another Pod for being ready using probes, hence the normally available readinessProbe.httpGet doesn't work for absolute remote urls. Still the workaround requested in this task should show how probes and Pod<->Service communication works.

First we create the first Pod:

Next perform the necessary additions manually:

Then create the Pod and confirm it's in a non-ready state:

We can also check the reason for this using describe:

Now we create the second Pod:

The already existing Service service-am-i-ready should now have an Endpoint:

Which will result in our first Pod being ready, just give it a minute for the Readiness probe to check again:

Look at these Pods working together!

 

 

Question 5 | Kubectl sorting

 

Solve this question on: ssh cka8448

 

Create two bash script files which use kubectl sorting to:

  1. Write a command into /opt/course/5/find_pods.sh which lists all Pods in all Namespaces sorted by their AGE (metadata.creationTimestamp)

  2. Write a command into /opt/course/5/find_pods_uid.sh which lists all Pods in all Namespaces sorted by field metadata.uid

 

Answer:

A good resources here (and for many other things) is the kubectl-cheat-sheet. You can reach it fast when searching for "cheat sheet" in the Kubernetes docs.

 

Step 1

We should be able to execute it and see sorting by AGE:

 

Step 2

For the second command we create file:

When we execute we should see a different sorting order:

 

 

Question 6 | Fix Kubelet

 

Solve this question on: ssh cka1024

 

There seems to be an issue with the kubelet on controlplane node cka1024, it's not running.

Fix the kubelet and confirm that the node is available in Ready state.

Create a Pod called success in default Namespace of image nginx:1-alpine.

 

ℹ️ The node has no taints and can schedule Pods without additional tolerations

 

Answer:

The procedure on scenarios like these is to first check if the kubelet is running. If it isn't start it, check its logs and fix issues if there are some. It could also be helpful to look at the config files of other clusters and diff/compare.

 

Investigate

Check node status:

Okay, this looks very wrong. First we check if the kubelet is running:

No kubectl process running, just the grep command itself is displayed. We check if the kubelet is configured as service, which is default for a kubeadm installation:

We can see it's not running (inactive) in this line:

But the kubelet is configured as a service with config at /usr/lib/systemd/system/kubelet.service, let's try to start it:

Above we see it's trying to execute /usr/local/bin/kubelet in this line:

It does so with some arguments defined in its service config file. A good way to find errors and get more info is to run the command manually:

That's the issue: wrong path to the kubelet binary.

 

Read Logs

Usually we need to dig a bit deeper and check logs using journalctl -u kubelet or cat /var/log/syslog | grep kubelet:

If we check logs we should always look at the time, we probably only want the latest ones. Here we see:

The logs don't show any error messages from the kubelet itself. Usually if the kubelet is started and exits because of an error, like an unknown argument passed, there will be error logs. But because there is nothing more here it could be a good idea to try to execute the kubelet binary manually.

We already did this above before checking the logs and it showed us that a wrong binary path was used in the service config file.

 

Fix the Kubelet

We go ahead and correct the path in file /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf:

In the very last line we updated the binary path to /usr/bin/kubelet.

Now we reload the service:

That looks much better. We can wait for the containers to appear, which can take a minute:

ℹ️ In this environment crictl can be used for container management. In the real exam this could also be docker. Both commands can be used with the same arguments.

Also the node should be available, give it a bit of time though:

ℹ️ It might take some time till k get node doesn't throw any errors after fixing the issue

Finally we create the requested Pod:

 

 

Question 7 | Etcd Operations

 

Solve this question on: ssh cka2560

 

You have been tasked to perform the following etcd operations:

  1. Run etcd --version and store the output at /opt/course/7/etcd-version

  2. Make a snapshot of etcd and save it at /opt/course/7/etcd-snapshot.db

 

Answer:
Step 1: Etcd Version

Here we simply need to execute a command, shouldn't be that hard:

Well, etcd is not installed directly on the controlplane but it runs as a Pod instead. So we do:

 

Step 2: Etcd Snapshot

First we log into the controlplane and try to create a snapshot of etcd:

But it fails or hangs because we need to authenticate ourselves. For the necessary information we can check the etc manifest:

We only check the etcd.yaml for necessary information we don't change it.

But we also know that the api-server is connecting to etcd, so we can check how its manifest is configured:

We use the authentication information and pass it to etcdctl:

Which should provide successful output:

ℹ️ Don't use snapshot status because it can alter the snapshot file and render it invalid in certain etcd versions

 

(Optional) Etcd Restore

ℹ️ Doing this wrong can leave this cluster broken and will affect this question and also others

We create a Pod in the cluster and wait for it to be running:

Next we stop all controlplane components:

It's very important to wait for all K8s controlplane containers to be removed before continuing. This can take a minute!

ℹ️ In this environment crictl can be used for container management. In the real exam this could also be docker. Both commands can be used with the same arguments.

Now we restore the snapshot into a specific directory:

We could specify another host to make the backup from by using etcdctl --endpoints http://IP, but here we just use the default value which is: http://127.0.0.1:2379,http://127.0.0.1:4001.

The restored files are located at the new folder /var/lib/etcd-snapshot, now we have to tell etcd to use that directory:

Now we move all controlplane yaml again into the manifest directory. Give it some time (up to several minutes) for etcd to restart and for the api-server to be reachable again:

Then we check again for the Pod:

Awesome, snapshot and restore worked as our Pod is gone.

 

 

Question 8 | Get Controlplane Information

 

Solve this question on: ssh cka8448

 

Check how the controlplane components kubelet, kube-apiserver, kube-scheduler, kube-controller-manager and etcd are started/installed on the controlplane node.

Also find out the name of the DNS application and how it's started/installed in the cluster.

Write your findings into file /opt/course/8/controlplane-components.txt. The file should be structured like:

Choices of [TYPE] are: not-installed, process, static-pod, pod

 

Answer:

We could start by finding processes of the requested components, especially the kubelet at first:

We can see which components are controlled via systemd looking at /usr/lib/systemd directory:

This shows kubelet is controlled via systemd, but no other service named kube nor etcd. It seems that this cluster has been setup using kubeadm, so we check in the default manifests directory:

The kubelet could also have a different manifests directory specified via a KubeletConfiguration, but the one above is the default one.

This means the main 4 controlplane services are setup as static Pods. Actually, let's check all Pods running on in the kube-system Namespace:

Above we see the 4 static pods, with -cka8448 as suffix.

We also see that the dns application seems to be coredns, but how is it controlled?

Seems like coredns is controlled via a Deployment. We combine our findings in the requested file:

You should be comfortable investigating a running cluster, know different methods on how a cluster and its services can be setup and be able to troubleshoot and find error sources.

 

 

Question 9 | Kill Scheduler, Manual Scheduling

 

Solve this question on: ssh cka5248

 

Temporarily stop the kube-scheduler, this means in a way that you can start it again afterwards.

Create a single Pod named manual-schedule of image httpd:2-alpine, confirm it's created but not scheduled on any node.

Now you're the scheduler and have all its power, manually schedule that Pod on node cka5248. Make sure it's running.

Start the kube-scheduler again and confirm it's running correctly by creating a second Pod named manual-schedule2 of image httpd:2-alpine and check if it's running on cka5248-node1.

 

Answer:
Stop the Scheduler

First we find the controlplane node:

Then we connect and check if the scheduler is running:

Kill the Scheduler (temporarily):

And it should be stopped, we can wait for the container to be removed with watch crictl ps:

ℹ️ In this environment crictl can be used for container management. In the real exam this could also be docker. Both commands can be used with the same arguments.

 

Create a Pod

Now we create the Pod:

And confirm it has no node assigned:

 

Manually schedule the Pod

Let's play the scheduler now:

The scheduler sets the nodeName for a Pod declaration. How it finds the correct node to schedule on, that's a very much complicated matter and takes many variables into account.

As we cannot kubectl apply or kubectl edit , in this case we need to delete and create or replace:

How does it look?

It looks like our Pod is running on the controlplane now as requested, although no tolerations were specified. Only the scheduler takes taints/tolerations/affinity into account when finding the correct node name. That's why it's still possible to assign Pods manually directly to a controlplane node and skip the scheduler.

 

Start the scheduler again

Checks it's running:

Schedule a second test Pod:

Back to normal.

 

 

Question 10 | PV PVC Dynamic Provisioning

 

Solve this question on: ssh cka6016

 

There is a backup Job which needs to be adjusted to use a PVC to store backups.

Create a StorageClass named local-backup which uses provisioner: rancher.io/local-path and volumeBindingMode: WaitForFirstConsumer. To prevent possible data loss the StorageClass should keep a PV retained even if a bound PVC is deleted.

Adjust the Job at /opt/course/10/backup.yaml to use a PVC which request 50Mi storage and uses the new StorageClass.

Deploy your changes, verify the Job completed once and the PVC was bound to a newly created PV.

 

ℹ️ To re-run a Job, delete it and create it again

 

ℹ️ The abbreviation PV stands for PersistentVolume and PVC for PersistentVolumeClaim

 

Answer:

The StorageClass should use provider rancher.io/local-path, which is of the project Local Path Provisioner. This project works with Dynamic Volume Provisioning, but instead of creating actual volumes it uses local storage on the node where the Pod runs, by default at path /opt/local-path-provisioner.

Cloud companies like AWS or GCP provide their own StorageClasses and providers, which if used for PVCs create PVs backed by actual volumes in the cloud account.

 

Create StorageClass

First we can have a look at existing ones:

The local-path is the default one available if the Local Path Provisioner is installed. But we can see it has a reclaimPolicy of Delete. Still we could use this one as template for the one we need to create:

We need to use reclaimPolicy: Retain because this will cause the PV to not get deleted even after the associated PVC is deleted. It's very easy to delete resources in Kubernetes which can lead to quick data loss. Especially in this case where important data, like from a backup, is in play.

This looks like what we want. Now we have the choice between two StorageClasses.

 

Check existing Job

Let's have a look at the existing Job:

Currently it uses an emptyDir volume which means in only stores data in the temporary filesystem of the Pod. This means once the Pod is deleted the data is deleted as well.

We could go ahead and create it now to see if everything else works:

Looks like it completed without errors.

 

Adjust Job template

For this we first need to create a PVC and then use in the Job template:

We first made a backup of the provided file, which is always a good idea. Then we added the new PVC and referenced the PVC in the Pod volumes: section.

 

Deploy changes and verify

First we delete the existing Job because we did create it once before without any changes. And then we deploy:

Then we should see the Job execution created a Pod which used the PVC which created a PV:

 

Optional investigation

Because the Local Path Provisioner is used we can actually see the volume represented on the filesystem. And because this cluster only has one node, and we're already on it, we can simply do:

If we run the Job again we should see another backup file:

And if we delete the PVC we should still see the PV and the files in the volume (filesystem in this case):

ℹ️ Removing the PVC and Job might affect your scoring for this question, so best create them again after testing deletion

We can no longer see the PVC, but the PV is in status Released. This is because we set the reclaimPolicy: Retain in the StorageClass. Now we could manually export/rescue the data in the volume and afterwards delete the PV manually.

 

 

Question 11 | Create Secret and mount into Pod

 

Solve this question on: ssh cka2560

 

Create Namespace secret and implement the following in it:

  • Create Pod secret-pod with image busybox:1. It should be kept running by executing sleep 1d or something similar

  • Create the existing Secret /opt/course/11/secret1.yaml and mount it readonly into the Pod at /tmp/secret1

  • Create a new Secret called secret2 which should contain user=user1 and pass=1234. These entries should be available inside the Pod's container as environment variables APP_USER and APP_PASS

 

Answer

First we create the Namespace:

 

Secret 1

To create the existing Secret we need to adjust the Namespace for it:

 

Secret 2

Next we create the second Secret:

 

Pod

Now we create the Pod template:

Then make the necessary changes:

And execute:

Finally we verify:

 

 

Question 12 | Schedule Pod on Controlplane Nodes

 

Solve this question on: ssh cka5248

 

Create a Pod of image httpd:2-alpine in Namespace default.

The Pod should be named pod1 and the container should be named pod1-container.

This Pod should only be scheduled on controlplane nodes.

Do not add new labels to any nodes.

 

Answer:

First we find the controlplane node(s) and their taints:

Next we create the Pod yaml:

 

Solution using NodeSelector

Use the K8s docs and search for tolerations and nodeSelector to find examples, then update:

ℹ️ The nodeSelector specifies node-role.kubernetes.io/control-plane with no value because this is a key-only label and we want to match regardless of the value

Important here to add the toleration for running on controlplane nodes, but also the nodeSelector to make sure it only runs on controlplane nodes. If we just specify a toleration the Pod can be scheduled on controlplane or worker nodes.

 

Solution using NodeAffinity

We could also use nodeAffinity instead of nodeSelector, although in this case it is more complex and not really suggested:

Using nodeAffinity still requires the toleration.

 

Verify

Now we create the Pod and and check if is scheduled:

We can see the Pod is scheduled on the controlplane node.

 

 

Question 13 | Multi Containers and Pod shared Volume

 

Solve this question on: ssh cka3200

 

Create a Pod with multiple containers named multi-container-playground in Namespace default:

  • It should have a volume attached and mounted into each container. The volume shouldn't be persisted or shared with other Pods

  • Container c1 with image nginx:1-alpine should have the name of the node where its Pod is running on available as environment variable MY_NODE_NAME

  • Container c2 with image busybox:1 should write the output of the date command every second in the shared volume into file date.log. You can use while true; do date >> /your/vol/path/date.log; sleep 1; done for this.

  • Container c3 with image busybox:1 should constantly write the content of file date.log from the shared volume to stdout. You can use tail -f /your/vol/path/date.log for this.

     

ℹ️ Check the logs of container c3 to confirm correct setup

 

Answer:

First we create the Pod template:

And add the other containers and the commands they should execute:

Well, there was a lot requested here! We check if everything is good with the Pod:

Not a bad start. Now we check if container c1 has the requested node name as env variable:

And finally we check the logging, which means that c2 correctly writes and c3 correctly reads and outputs to stdout:

 

 

Question 14 | Find out Cluster Information

 

Solve this question on: ssh cka8448

 

You're ask to find out following information about the cluster:

  1. How many controlplane nodes are available?

  2. How many worker nodes (non controlplane nodes) are available?

  3. What is the Service CIDR?

  4. Which Networking (or CNI Plugin) is configured and where is its config file?

  5. Which suffix will static pods have that run on cka8448?

Write your answers into file /opt/course/14/cluster-info, structured like this:

 

Answer:
How many controlplane and worker nodes are available?

We see one controlplane and no worker nodes.

 

What is the Service CIDR?

 

Which Networking (or CNI Plugin) is configured and where is its config file?

By default the kubelet looks into /etc/cni/net.d to discover the CNI plugins. This will be the same on every controlplane and worker nodes.

 

Which suffix will static pods have that run on cka8448?

The suffix is the node hostname with a leading hyphen.

 

Result

The resulting /opt/course/14/cluster-info could look like:

 

 

Question 15 | Cluster Event Logging

 

Solve this question on: ssh cka6016

 

  1. Write a kubectl command into /opt/course/15/cluster_events.sh which shows the latest events in the whole cluster, ordered by time (metadata.creationTimestamp)

  2. Delete the kube-proxy Pod and write the events this caused into /opt/course/15/pod_kill.log on cka6016

  3. Manually kill the containerd container of the kube-proxy Pod and write the events into /opt/course/15/container_kill.log

 

Answer:

 

Step 1

And we can execute it which should show recent events:

 

Step 2

We delete the kube-proxy Pod:

Now we can check the events, for example by using the command that we created before:

Write the events caused by the deletion into /opt/course/15/pod_kill.log on cka6016:

 

Step 3

ℹ️ Node cka6016 is already the controlplane and the only node of the cluster. Otherwise we might have to ssh onto the correct worker node where the Pod is running instead

 

Finally we will try to provoke events by killing the container belonging to the container of a kube-proxy Pod:

ℹ️ In this environment crictl can be used for container management. In the real exam this could also be docker. Both commands can be used with the same arguments.

We killed the container (2fd052f1fcf78), but also noticed that a new container (6bee4f36f8410) was directly created again. Thanks Kubernetes!

Now we see if this caused events again and we write those into the second file:

Write the events caused by the killing into /opt/course/15/container_kill.log on cka6016:

Comparing the events we see that when we deleted the whole Pod there were more things to be done, hence more events. For example was the DaemonSet in the game to re-create the missing Pod. Where when we manually killed the main container of the Pod, the Pod still exists but only its container needed to be re-created, hence less events.

 

 

Question 16 | Namespaces and Api Resources

 

Solve this question on: ssh cka3200

 

Write the names of all namespaced Kubernetes resources (like Pod, Secret, ConfigMap...) into /opt/course/16/resources.txt.

Find the project-* Namespace with the highest number of Roles defined in it and write its name and amount of Roles into /opt/course/16/crowded-namespace.txt.

 

Answer:
Namespace and Namespaces Resources

We can get a list of all resources:

So we write them into the requested location:

Which results in the file:

 

Namespace with most Roles

Finally we write the name and amount into the file:

 

 

Question 17 | Operator, CRDs, RBAC, Kustomize

 

Solve this question on: ssh cka6016

 

There is Kustomize config available at /opt/course/17/operator. It installs an operator which works with different CRDs. It has been deployed like this:

Perform the following changes in the Kustomize base config:

  1. The operator needs to list certain CRDs. Check the logs to find out which ones and adjust the permissions for Role operator-role

  2. Add a new Student resource called student4 with any name and description

Deploy your Kustomize config changes to prod.

 

 

Answer:

Kustomize is a standalone tool to manage K8s Yaml files, but it also comes included with kubectl. The common idea is to have a base set of K8s Yaml and then override or extend it for different overlays, like done here for prod:

 

Investigate Base

Let's investigate the base first for better understanding:

Running kubectl kustomize DIR will build the whole Yaml based on whatever is defined in the kustomization.yaml.

In the case above we did build for the base directory, which produces Yaml that is not expected to be deployed just like that. We can see for example that all resources contain namespace: NAMESPACE_REPLACE entries which won't be possible to apply because Namespace names need to be lowercase.

But for debugging it can be useful to build the base Yaml.

 

Investigate Prod

We can see that all resources now have namespace: operator-prod. Also prod adds the additional label project_id: prod_7768e94e-88da-4744-9135-f1e7fbb96daf to the Deployment. The rest is taken from base.

 

Locate Issue

The instructions tell us to check the logs:

We can see that the operator tries to list resources students and classes. If we look at the Deployment we can see that it simply runs kubectl commands in a loop:

 

Adjust RBAC

Now we need to adjust the existing Role operator-role. In the Kustomize config directory we find file rbac.yaml which we need to edit. Instead of manually editing the Yaml we could also generate it via command line:

Now we copy&paste it into rbac.yaml:

And we deploy:

We can see that only the Role was configured, which is what we want. And the logs are not throwing errors any more:

 

Create new Student resource

Finally we need to create a new Student resource. Here we can simply copy an existing one in students.yaml:

And we deploy:

Only Student student4 got created, everything else stayed the same.

tips

CKA Tips Kubernetes 1.33

In this section we'll provide some tips on how to handle the CKA exam and browser terminal.

 

Knowledge

Study all topics as proposed in the curriculum until you feel comfortable with all.

 

General

  • Study all topics as proposed in the curriculum until you feel comfortable with all

  • Do 1 or 2 test sessions with this CKA Simulator. Understand the solutions and maybe try out other ways to achieve the same thing.

  • Setup your aliases, be fast and breathe kubectl

  • The majority of tasks in the CKA will also be around creating Kubernetes resources, like it's tested in the CKAD. So preparing a bit for the CKAD can't hurt.

  • Learn and Study the in-browser scenarios on https://killercoda.com/killer-shell-cka (and maybe for CKAD https://killercoda.com/killer-shell-ckad)

  • Imagine and create your own scenarios to solve

 

Components

  • Understanding Kubernetes components and being able to fix and investigate clusters: https://kubernetes.io/docs/tasks/debug-application-cluster/debug-cluster

  • Know advanced scheduling: https://kubernetes.io/docs/concepts/scheduling/kube-scheduler

  • When you have to fix a component (like kubelet) in one cluster, just check how it's setup on another node in the same or even another cluster. You can copy config files over etc

  • If you like you can look at Kubernetes The Hard Way once. But it's NOT necessary to do, the CKA is not that complex. But KTHW helps understanding the concepts

  • You should install your own cluster using kubeadm (one controlplane, one worker) in a VM or using a cloud provider and investigate the components

  • Know how to use Kubeadm to for example add nodes to a cluster

  • Know how to create an Ingress resources

  • Know how to snapshot/restore ETCD from another machine

 

 

CKA Exam Info

Read the Curriculum

https://github.com/cncf/curriculum

Read the Handbook

https://docs.linuxfoundation.org/tc-docs/certification/lf-handbook2

Read the important tips

https://docs.linuxfoundation.org/tc-docs/certification/tips-cka-and-ckad

Read the FAQ

https://docs.linuxfoundation.org/tc-docs/certification/faq-cka-ckad

 

Kubernetes documentation

Get familiar with the Kubernetes documentation and be able to use the search. Allowed resources are:

ℹ️ Verify the list here

 

The Exam UI / Remote Desktop

The real exam, as well as the simulator, provides a Remote Desktop (XFCE) on Ubuntu/Debian. Coming from OSX/Windows there will be changes in copy&paste for example.

Official Information

ExamUI: Performance Based Exams

Lagging

There could be some lagging, definitely make sure you are using a good internet connection because your webcam and screen are transferring all the time.

Kubectl autocompletion and commands

The following are installed or pre-configured, verify the list here:

  • kubectl with k alias and Bash autocompletion

  • yq or YAML processing

  • curl and wget for testing web services

  • man and man pages for further documentation

ℹ️ You're allowed to install tools, like tmux for terminal multiplexing or jq for JSON processing

Copy & Paste

Copy and pasting will work like normal in a Linux Environment:

What always works: copy+paste using right mouse context menu What works in Terminal: Ctrl+Shift+c and Ctrl+Shift+v What works in other apps like Firefox: Ctrl+c and Ctrl+v

Score

There are 15-20 questions in the exam. Your results will be automatically checked according to the handbook. If you don't agree with the results you can request a review by contacting the Linux Foundation Support.

Notepad & Flagging Questions

You can flag questions to return to later. This is just a marker for yourself and won't affect scoring. You also have access to a simple notepad in the browser which can be used to store any kind of plain text. It might make sense to use this and write down additional information about flagged questions. Instead of using the notepad you could also open Mousepad (XFCE application inside the Remote Desktop) or create a file with Vim.

VSCodium

You can use VSCodium to edit files and you can also use its terminal to run commands. You're not allowed to install any VSCodium extensions.

Servers

Each question needs to be solved on a specific instance other than your main terminal. You'll need to connect to the correct instance via ssh, the command is provided before each question.

 

PSI Bridge

Starting with PSI Bridge:

  • The exam will now be taken using the PSI Secure Browser, which can be downloaded using the newest versions of Microsoft Edge, Safari, Chrome, or Firefox

  • Multiple monitors will no longer be permitted

  • Use of personal bookmarks will no longer be permitted

The new ExamUI includes improved features such as:

  • A remote desktop configured with the tools and software needed to complete the tasks

  • A timer that displays the actual time remaining (in minutes) and provides an alert with 30, 15, or 5 minute remaining

  • The content panel remains the same (presented on the Left Hand Side of the ExamUI)

Read more here.

 

Terminal Handling

 

Bash Aliases

In the real exam, each question has to be solved on a different instance to which you connect via ssh. This means it's not advised to configure bash aliases because they wouldn't be available on the instances accessed by ssh.

 

Be fast

Use the history command to reuse already entered commands or use even faster history search through Ctrl +r .

If a command takes some time to execute, like sometimes kubectl delete pod x. You can put a task in the background using Ctrl +z and pull it back into foreground running command fg.

You can delete pods fast with:

 

Vim

Be great with vim.

Settings

In case you face a situation where vim is not configured properly and you face for example issues with pasting copied content you should be able to configure via ~/.vimrc or by entering manually in vim settings mode:

The expandtab option makes sure to use spaces for tabs.

Note that changes in ~/.vimrc will not be transferred when connecting to other instances via ssh.

Toggle vim line numbers

When in vim you can press Esc and type :set number or :set nonumber followed by Enter to toggle line numbers. This can be useful when finding syntax errors based on line - but can be bad when wanting to mark&copy by mouse. You can also just jump to a line number with Esc :22 + Enter.

Copy&Paste

Get used to copy/paste/cut with vim:

Indent multiple lines

To indent multiple lines press Esc and type :set shiftwidth=2. First mark multiple lines using Shift v and the up/down keys. Then to indent the marked lines press > or <. You can then press . to repeat the action.